Methods and systems for creating new domains

ABSTRACT

Systems and methods for creating a new domain, such as a top-level domain or a second-level domain, make use of a Domain Manager that enables a user to enter data that is necessary or optional to implement the creation of a new domain. Systems such as, for example, a Registry and one or more Registrars, may use the data defined by the Domain Manager to create a new domain.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.13/339,466 filed Dec. 29, 2011, entitled “METHODS AND SYSTEMS FORCREATING NEW DOMAINS”, which is incorporated herein by reference.

TECHNICAL FIELD

This application is directed towards methods and systems for creation ofnew domains, including the creation of new top level domains and newsecond level domains.

BACKGROUND

A domain name system (DNS) allows people using the internet to refer todomain names, rather than IP addresses, when accessing websites andother online services. Domain names, which employ text characters, suchas letters, numbers, and hyphens, will often be easier to remember thanIP addresses, which are numerical and do not contain letters or hyphens.In order to implement a DNS, a variety of top-level domains (TLDs) havebeen created. A generic top-level domain (gTLD) is one type of top-leveldomain used in DNS. Examples of gTLDs that have already been created are“.com,” “.net,” and “.org.” Another type of TLD is a country-codetop-level domain (ccTLD) such as, for example, “.uk.”

One or more second-level domains (SLDs) can be registered under a TLD.For example, a SLD of “verisign” could be registered under the TLD“.com” such that a website could be accessed at “verisign.com.”

A domain name “Registry” is an entity that creates, that is, “registers”TLDs, and stores data regarding TLDs and SLDs to be registered under therespective TLDs. A Registry may make stored data regarding TLDsavailable to one or more “Registrars.” A Registrar may receive data fromcustomers desiring to register one or more SLDs under a given TLD andmay communicate this data to the Registry for storage.

The creation and administration of a new TLD or a new SLD requiresseveral changes to be made at a Registry, at one or more Registrars, andat a variety of other services such as DNS servers and Whois. In orderfor a Registry to store data regarding TLDs and SLDs registered underthe respective TLDs, data regarding a new TLD may need to be enteredinto a Registry. In addition, in order for a Registrar to register SLDsunder TLDs, data regarding a new TLD may need to be provided to theRegistrars. It is desirable to provide an improved method for performingthe steps necessary to create a new TLD or a new SLD.

SUMMARY

In one disclosed embodiment, a computer-implemented method of creating anew domain is performed. The method includes receiving domain dataregarding an unregistered domain at a first system, the domain datacomprising a domain name and data defining at least one of: services tobe supported by the domain, features to be supported by the domain, orpolicies to be enforced by the domain. The method further includescreating a data structure comprising the domain data. The method furtherincludes transmitting the created data structure to a second system.

In another disclosed embodiment, a system for creating a new domain isprovided. The system includes a processor, a memory, an input device, adata structure creation module, and a communication module. The inputdevice is coupled to the processor to receive domain data regarding anunregistered domain, the domain data comprising a domain name and datadefining at least one of: services to be supported by the domain,features to be supported by the domain, or policies to be enforced bythe domain. The data structure creation module is coupled to theprocessor and provides for creating a data structure comprising thedomain data. The communication module provides for transmitting the datastructure to a second system.

In another disclosed embodiment, a system for creating a new domain isprovided. The system includes a processor, a memory, a communicationmodule, and one or more databases. The communication module is coupledto the processor and provides for receiving data from a first systemregarding an unregistered domain that is being created as a new domain.The one or more databases provide for storing at least some of thereceived data, wherein the stored data comprises a domain name and datadefining at least one of: services supported by the domain, featuressupported by the domain, or policies enforced by the domain.

Additional aspects related to the embodiments will be set forth in partin the description which follows, and in part will be obvious from thedescription, or may be learned by practice of the invention.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system in which one Registry and multipleRegistrars are used when creating a new top-level domain.

FIG. 2 illustrates a system in which one Registry and one Registrar areused when creating a new top-level domain.

FIG. 3 illustrates a system in which a managed DNS service is used whencreating a new top-level domain

FIG. 4 is a flow chart of a registration method for a new domainaccording to one embodiment.

FIG. 5 is an example of a user interface of a Domain Manager accordingto one embodiment.

FIG. 6 is a flow chart of a top-level and second-level domainregistration method for a new domain according to one embodiment.

FIG. 7 is a flow chart of a registration method for a new second-leveldomain according to one embodiment.

FIG. 8 is a flow chart of a domain feature and policy obtaining methodaccording to one embodiment.

FIG. 9 is a flow chart of a second-level domain registration and pricingmethod according to one embodiment.

FIG. 10 is a flow chart of a Resolution Services enablement methodaccording to one embodiment.

FIG. 11 is a flow chart of a billing and invoicing method according toone embodiment.

FIG. 12 is a flow chart of a report generating method according to oneembodiment.

FIG. 13 is a flow chart of a report generating method according to oneembodiment.

FIG. 14 is a flow chart of a report generating method according to oneembodiment.

FIG. 15 is an example of a user interface of a Domain Manager accordingto one embodiment.

DETAILED DESCRIPTION

Reference will now be made in detail to the exemplary embodiments,examples of which are illustrated in the accompanying drawings. Whereverpossible, the same reference numbers will be used throughout thedrawings to refer to the same or like parts.

The process of creating a new domain can be expedited by configuring thedata flow in a system used to create a new domain. For instance, in someembodiments, a computer system in the form of a Domain Manager may beprovided to obtain some or all of the data necessary to create andadminister a new domain. Further, in some embodiments, a system, such asa Registry, that creates the new domain can be structured to accept datafrom the Domain Manager, store and use portions of the data, andtransmit portions of the data to other systems.

FIG. 1 depicts a system 1000 in which one Registry 1010 and multipleRegistrars 1110 are used when introducing a new top-level domain. Anarrangement such as that disclosed in FIG. 1 may be used when a genericTLD is being created.

A network 1005, such as the internet or an intranet, may interconnectthe Registry 1010, the Registrars 1110, a Domain Manager 1070, and theone or more Resolution Services 1160, to enable Registry 1010, theRegistrars 1110, the Domain Manager 1070, and the one or more ResolutionServices 1160 to communicate with each other.

The Registry 1010 may include one or more processors 1020, one or morememories 1030, and one or more databases, such as a NameStore CustomerConsole (NCC) database 1040 and a Consolidated Top Level Domain database1050 (otherwise known as a Provisioning Database). The NCC database mayinclude information regarding Accounts (Accounts may be associated withRegistrars and/or Registry Internal Accounts), a product catalog (forexample, one product per TLD), subscriptions from the Accounts to theproducts, security groups that are assigned to individual users, andaggregate financial information. The Registry 1010 may also include aCommunication Module 1240 to facilitate transmitting data to, andreceiving data from, systems external to the Registry. The Registry 1010may also include EPP 1170, User Interface 1180, Batch 1190, Reports1220, and Data Escrow server 1230. EPP 1170 may facilitate securecommunications between the Registrars and the Registry. User Interface1180 may allow a user to access components of the Registry. Batch 1190may update the available credit of an Account and perform otherasynchronous actions. Reports server 1220 may store reports havinginformation regarding domains that have been registered, for use byvarious entities such as the Registry, Registrars, or ICANN. Data Escrowserver 1230 may store reports having information regarding domains thathave been registered and corresponding pricing information, for use byan escrow agent. The processor 1020 could be a server, a microprocessor,or any circuit capable of electrically coupling the components of theRegistry. The Registry may operate in the manner described in any one ofthe embodiments below discussing the functions of the Registry.

A plurality of Registrars 1110 may include one or more processors 1120,one or more memories 1130, and one or more databases 1140. TheRegistrars 1110 may also include a Communication Module 1260 tofacilitate transmitting data to, and receiving data from, systemsexternal to the Registrars. The processor 1120 could be a server, amicroprocessor, or any circuit capable of electrically coupling the oneor more databases, the one or more memories, and the CommunicationModule. The Registrars may operate in the manner described in any one ofthe embodiments below discussing the functions of a Registrar.

A Domain Manager 1070 may be provided with one or more processors 1090,one or more memories 1100, and one or more user interfaces 1080. TheDomain Manager 1070 may also include a Communication Module 1250 tofacilitate transmitting data to, and receiving data from, systemsexternal to the Domain Manager. The Domain Manager 1070 may also includea Data Structure Creation Module 1270 to facilitate creation of a datastructure based on information acquired from the user interface 1080.The processor 1090 could be a PC, a microprocessor, or any circuitcapable of electrically coupling the one or more user interfaces, theone or more memories, the Communication Module, and the Data StructureCreation Module. The Domain Manager may operate in the manner describedin any one of the embodiments below discussing the functions of theDomain Manager. The Domain Manager 1070 is depicted in FIG. 1 as being aseparate system that can be reached via network 1005, however, it is tobe appreciated that the Domain Manager could also be located in theRegistry 1010.

A plurality of Resolution Services 1160 may be provided. ResolutionServices 1160 may include a DNS server 1200 and a Whois server 1210. TheDNS server may store a mapping of domain names to IP addresses. TheWhois server may store data regarding customers that have registereddomain names.

FIG. 2 depicts a system 2000 for introducing a new top-level domain. Thecomponents of system 2000 operate in substantially the same manner assystem 1000, but the system 2000 includes only a single Registry and asingle Registrar. Whereas system 1000 may be used for introduction of,for example, gTLDs similar to “.com” and “.net,” system 2000 may be usedfor introduction of, for example, “vanity” domains such as “.London.”

FIG. 3 depicts a system 3000 in which a managed DNS service is used whenintroducing a new top-level domain. The components of system 3000operate in substantially the same manner as system 1000. However, in themanaged DNS service scenario, the managed DNS service assumes the roleof both the Registry and the Registrar.

FIG. 4 depicts a registration method 400 for a user, such as an employeeof a Registry, to create a new domain according to one embodiment. Themethod 400 begins by receiving user input data via user interface 1080of Domain Manager 1070. The Domain Manager 1070 employs the receiveddata to define one or more of a domain name, domain services (svcs),domain features and domain policies of a new domain (step 410). TheDomain Manager 1070 may be a software application running on a server,and may be configured to receive user data to define and create a newdomain at any level, including a top-level domain (TLD) and asecond-level domain (SLD). A new domain so defined may then beadministered by the Registry 1010.

The domain svcs defined by the Domain Manager 1070 when a new TLD isbeing created may include a list of one or more Extensible ProvisioningProtocol (EPP) objects and command-response extension Uniform ResourceIdentifiers (URIs). The EPP objects may be used to configure an EPP tofacilitate secure communications between Registrars and a Registry.

URIs may be used to uniquely identify an object service or extension inXML. An object service or extension may be defined using an XML schemawith a unique XML URI. By including a list of EPP objects andcommand-response extension URIs, an Account may know what objects andextensions a particular domain supports. For example, two versions ofthe DNSSEC extension may be supported. Both of the extensions could besupported or a single one, so by including the URI the Account may knowwhat it can use with a domain.

When a new SLD is being created with the Domain Manager, the DomainManager may also define domain svcs to determine which TLDs areappropriate, based on the defined domain svcs.

The domain features defined by the Domain Manager when a new TLD isbeing created may include an identifier indicating whether the TLD is“thick” or “thin.” With a thick TLD, contact information is required fordomains, whereas with a thin TLD, contact information is not supported.

The domain features defined by the Domain Manager when a new TLD isbeing created may further include an identifier indicating whether theTLD supports internationalized domain names. An internationalized domainname allows for the use of characters from non-English languages, suchas Chinese, Hindi, Arabic, Russian, or languages that use Latindiacritical characters.

The domain features defined by the Domain Manager when a new TLD isbeing created may further include an identifier indicating whetherdomain name system security extensions (DNSSEC) are supported and, ifso, which version is supported. DNSSEC 1.0 defined in RFC 4310, DNSSEC1.1 defined in RFC 5910, or both may be supported. In addition, policiessuch as whether the DS Data Interface or Key Data Interface is supportedin RFC 5910 and what algorithms are supported can be defined.

The domain features defined by the Domain Manager when a new TLD isbeing created may further include a list of levels supported by the TLD.For example the list of levels may indicate “2” for second level supportand “3” for third level support.

The domain policies defined by the Domain Manager when a new TLD isbeing created may include policies for a specific domain label, bylevel. For example, the policies regarding the specific domain label mayinclude information, for each level (i.e., top-level domain,second-level domain, third-level domain, etc.), regarding one or moreof: a minimum number of characters, a maximum number of characters, arequirement for the label to start with an alphanumeric character, arequirement for the label to end with an alphanumeric character, or arequirement that only DNS characters (upper and lower case Latincharacters, numbers, and a hyphen) be supported.

In addition, the domain policies defined by the Domain Manager when anew TLD is being created may further include information regarding theminimum number of name servers required and/or the maximum number ofname servers.

In addition, the domain policies defined by the Domain Manager when anew TLD is being created may further include a list of contact types,such as a registrant, an administrator, a technology contact, or abilling contact, and whether they are required or optional.

In addition, the domain policies defined by the Domain Manager when anew TLD is being created may further include DNSSEC policies. The DNSSECpolicies may include the minimum number of delegation signer (DS)resource records in the case of a thin DNSSEC TLD or the minimum numberof DNSKEY in the case of a thick DNSSEC TLD. The DNSSEC policies mayalso include the maximum number of delegation signer (DS) resourcerecords in the case of a thin DNSSEC TLD or the maximum number of DNSKEYin the case of a thick DNSSEC TLD. A “thick” DNSSEC TLD may support theKey Data Interface of RFC 5910 and a “thin” DNSSEC TLS may support theDS Data Interface of RFC 5910.

In addition, the domain policies defined by the Domain Manager when anew TLD is being created may further include authorization informationformat policies. The authorization information format policies mayinclude one or more of a minimum length, a maximum length, an indicationof whether a numeric character is required, an indication of whether analpha character is required, or an indication of whether a specialcharacter is required.

In addition, the domain policies defined by the Domain Manager when anew TLD is being created may further include information regarding whatelements are not returned on a partial information response fornon-sponsoring Accounts. If a querying Account is not the sponsoringAccount (a sponsoring Account being a Registrar or Registry InternalAccount that created the domain) and the Account does not provide validauthorization information, such as a private password that the Registrarmay provide, server policy determines which optional elements arereturned.

The domain policies defined by the Domain Manager when a new TLD isbeing created may further include one or more minimum registrationperiods with a command attribute to indicate commands, such as create,renew, or transfer, to which a given minimum registration periodapplies.

The domain policies defined by the Domain Manager when a new TLD isbeing created may further include one or more maximum registrationperiods with a command attribute to indicate commands, such as create,renew, or transfer, to which a given maximum registration periodapplies.

A new SLD may be created with the Domain Manager in the same way as aTLD. A domain label may be specified (that is, TLD or SLD) along withthe domain features and policies, in order to create a TLD or a SLD. AnSLD created with the Domain Manager would show up similarly to a TLD,except a SLD would allow registration of third level domains, whereas aTLD would allow registration of second level domains.

Once the Domain Manager has defined one or more of a domain name, domainsvcs, domain features and domain policies of a new domain (step 410),one or more databases at the Registry may be updated with some or all ofthe defined data (step 420). In some embodiments the Domain Manager willbe located within the Registry. In embodiments where the Domain Manageris located within the Registry, the data acquired by the user interfaceof the Domain Manager may be transmitted to databases at the Registryusing, for example, an intranet.

In some embodiments, the Domain Manager may be accessed by an internalDomain Manager User Interface to allow Registry administrators tocreate, update, and delete domains. In some embodiments, the DomainManager may also, or alternatively, be access by an external DomainManager User Interface to allow entities external to the Registry tocreate, update and delete domains. In some embodiments, such externalentities may be limited to making information queries (i.e., readoperations).

When a new domain is being created using the Domain Manager, a NameStoreCustomer Console (NCC) database in the Registry may be updated toinclude additional product information such that the new domain is anavailable product (step 420). The update of the NameStore CustomerConsole database may be performed when the domain is deployed. Inaddition, when a new domain is being created using the Domain Manager,the Registry may update a Consolidated Top Level Domain database in theRegistry to include pricing data and other associated metadata regardingthe new domain (step 420). The pricing data could include, for example,a price or a range of prices to be charged for registering a SLD under anew TLD. Updating of the Consolidated Top Level Domain database may becontrolled by the Domain Manager, and may be performed when the newdomain is deployed.

After the Registry has updated its databases with some or all of thedata defined by the Domain Manager (step 420), some or all of the dataregarding the new domain may be transmitted or otherwise made availableover one or more communication channels to one or more downstreamcomponents of the DNS system external to the Registry (step 430).Alternatively, such availability may be provided concurrently with theupdating of the one or more databases at the Registry. Data regarding anew domain may be made available to channels and downstream componentsbased upon pre-agreed upon database tables that can be queried by thedownstream components. The resolution services generally includeversions of the contents of the Provisioning database including domainmetadata. Using the domain metadata, the downstream components may bewritten to be data driven. The channels may include one or moreExtensible Provisioning Protocol (EPP) channels (for example, a singleEPP channel per Registry database). The downstream components mayinclude one or more of DNS, Whois, Reports, and Data Escrow.

It will also be appreciated that, in addition to being used to introducea new domain, the Domain Manager could be used to provide updates to oneor more of a domain name, domain svcs, domain features, and domainpolicies of a previously registered domain. Changes to data stored inthe various systems regarding the previously registered domain maypropagate through the various systems in substantially the same manneras data regarding a new domain.

FIG. 5 depicts an example of a user interface of a Domain Manageraccording to one embodiment. In the embodiment depicted in FIG. 5, atable 520 will be displayed with a variety of information regardingdomains that have been previously been created using the Domain Manager.For example, the table 520 may include a TLD name, a product prefix, anda current status of the creation process for TLDs that have beenpreviously created. In the embodiment depicted in FIG. 5, an add domainbutton 510 may also be provided on the display that initiates theprocess for creating a new domain.

FIG. 15 depicts an example of a user interface of a Domain Manageraccording to one embodiment, where the creation process of a new TLD maybegin. For example, the display depicted in FIG. 15 may be output aftera user has selected button 510. A user may be given the option, or maybe required, to configure a variety of settings for the new TLD. Oncethe user has finished selecting the options presented on the display, auser may be required to select a create domain button 1510. Uponselection of button 1510, new domain settings may begin to propagate,for example, to the Registry, Registrars and/or Resolution Services asdescribed above with reference to FIG. 4.

FIG. 6 depicts a new TLD and SLD registration method 600 according toone embodiment. Whereas FIG. 4 depicts a method of registering anydomain using the Domain Manager, FIG. 6 depicts a method where theDomain Manager is used to create a TLD, with SLDs subsequentlyregistered under the TLD. The method 600 begins by receiving user inputat a user interface of a Domain Manager. The user input includes data todefine one or more of a domain name, domain svcs, domain features anddomain policies of a new TLD using the user interface (step 610), insubstantially the same manner as described above with respect to step410 of FIG. 4.

After receiving the user input (step 610), one or more databases at theRegistry may be updated with the acquired information (step 620), insubstantially the same manner as step 420 of FIG. 4. After the Registryhas updated its databases with the new data, or concurrently therewith,data regarding the new TLD may be made available over one or morechannels to downstream components (step 630), in substantially the samemanner as step 430 of FIG. 4.

After the Registry has updated its databases, or concurrently therewith,data regarding the new TLD may also be made available to one or moreRegistrars (step 640). It will be recognized that while in someembodiments the Registry and the one or more Registrars will representseparate systems, in other embodiments, such as a managed DNS servicescenario, the Registry and Registrar functions will be within the samesystem.

Once the one or more Registrars have obtained the data regarding the newTLD, data may be received from the one or more Registrars to begin theregistration process for one or more new SLDs under the TLD (step 650).Whereas the TLD may be managed by the Registry, new SLDs registeredunder the TLD may be managed by the customers registering the respectivenew SLDs or may be managed by a Registrar. Alternatively, if the DomainManager were used to register new SLDs under the new TLD, the registeredSLDs could also be managed by the Registry.

A Registrar may determine which SLDs to register under a TLD. Dataregarding the new SLDs determined by a Registrar may be transmitted tothe Registry, whereby the Registry will store the data regarding the newSLDs in one or more databases (step 660). For instance, the Registry mayupdate a Provisioning Database to include the new SLDs, whereby theProvisioning Database stores data regarding some or all of the SLDsregistered under a TLD. After the Registry has updated its databases toaccount for the one or more new SLDs, or concurrently therewith, thedata regarding the new SLDs may be made available to each of severalchannels and to downstream components (step 670).

While FIG. 6 depicts a TLD being registered using the Domain Manager andan SLD then being registered below the TLD, it is to be appreciated thatany level domain (e.g., a second-level domain, third-level domain, etc.)could be registered using the Domain Manager, and subsequently a domaincould be registered one level below the domain registered via the DomainManager.

FIG. 7 depicts a second-level domain registration method 700 of a newTLD according to one embodiment. Prior to the start of the method 700, anew TLD will have been created. The method begins by having one or moreRegistrars query a Registry as to whether a new TLD is available (step710). The querying may be accomplished via a single virtual IP to whichthe one or more Registrars may connect. More details on using a virtualIP to implement the querying process may be found in U.S. patentapplication Ser. No. 12/543,462, published as U.S. Patent ApplicationPublication No. 2011/0047292, the subject matter of which isincorporated herein by reference. In performing the query, a Registrarmay request an immediate response from the Registry. Alternatively, theRegistry may place the Registrar's request in a queue and only respondto the Registrar's request when a new TLD has become available.

Once it is determined that a new TLD is available (step 720), theRegistrar making the query will receive data regarding the new TLD (step730). Using the received data, the Registrar may then begin theregistration process for a new set of SLDs under a TLD (step 740) insubstantially the same manner as steps 640-670 of FIG. 6.

FIG. 8 depicts a domain feature and policy obtaining method 800according to one embodiment. The method 800 depicts one example of animplementation for step 640 of FIG. 6. The method begins where aRegistrar queries a Registry for data on one or more new TLDs (step810). When the Registry receives the query and a new TLD is available,the Registry transmits to the Registrar one or more of: a TLD name, anEPP object and command-response extension URIs, TLD features, and TLDpolicies (step 820). The TLD name, EPP object and command-responseextension URIs, TLD features, and TLD policies are substantially thesame as those described in step 410 of FIG. 4. With the received data,the Registrar will be able to inform its customers of the name of thenew TLD and the various characteristics (svcs, features and policies) ofthe new TLD. In addition, the received data will indicate to theRegistrar what data it needs to acquire to register new SLDs under a newTLD.

FIG. 9 depicts a second-level domain registration and pricing method 600according to one embodiment. Prior to the start of the method 900, a newTLD will have been created. The method begins with a determination thata new TLD has become available (step 910).

Once it is determined that a new TLD has become available, adetermination may be made as to whether one or more Accounts have beenenabled for automatic subscriptions by searching a database at theRegistry that contains such information (step 920). An Account enabledfor automatic subscriptions may automatically start registering SLDswithin the new TLD. Accounts that are not enabled for automaticsubscriptions may be required to interact with a person at the Registryto create a TLD subscription before the Account can start registeringSLDs within the new TLD. After determining which Accounts are enabledfor automatic subscriptions, such Accounts may be automaticallysubscribed to a new TLD (step 930). Optionally, predetermined pricebands will be stored that can be used to automatically determine a priceto charge an Account for making use of the automatic subscription to thenew TLD (step 940).

FIG. 10 depicts a Resolution Services enablement method 4000 accordingto one embodiment. The method begins by providing a stream of changes ofthe Provisioning Database to one or more Resolution Services locatedexternal to the Registry (step 4020). The stream may be transformed in aformat useful to the target service.

A determination may then be made as to whether one or more triggerevents have occurred (step 4030). The one or more trigger events at step4030 may include, for example, a population of data in the ProvisioningDatabase exceeding a certain threshold, a TLD being added, a TLD beingupdated, and a TLD being deleted. If one or more trigger events haveoccurred, the stream will be validated to ensure that there is no issuewith the stream of transactions coming from the Provisioning Database tothe Resolution Service (step 4040). Validation may include comparing thetransformed data with the source data. Validation may be handled by theResolution Service. The Resolution Service may extract the desiredprovisioning data from the stream, transform the data, validate thedata, and propagate the data to resolution servers (e.g., DNS serversand/or Whois servers). The resolution servers generally have in-memoryimages of the transformed data with the provisioning database as theauthoritative source.

After the stream is validated at step 4040, one or more ResolutionService Resources will be provisioned (step 4050). Provisioning of oneor more Resolution Service Resources may include new TLD Servers andWhois Servers being setup, initialized, or updated. For example, a modelmay be setup to automatically allocate new resources or automaticallyenable new services in a Resolution Services Cloud for use by a newgTLD.

FIG. 11 depicts a billing and invoicing method 4100 according to oneembodiment. The method begins by obtaining billing data from theProvisioning Database (step 4110). The billing data represents amountsthat have been charged to Accounts for the registration of SLDs under agiven TLD. The billing data will be aggregated into aggregate debits andcredits that are applied to a given Account (step 4120). Afteraggregating the billing data, the aggregate billing data may be appliedto respective Accounts in the Account database (step 4130). Optionally,an Update Available Credit component may control the billing when a newTLD application is deployed. After the billing data is processed, aninvoice report may be updated (step 4140). The invoice report maydynamically add a new TLD based on the metadata and the billing datapopulated in the Provisioning Database.

A variety of entities, such as the Registry, the Registrars, and ICANN,may require the generation of reports. The Domain Manager may populatedata in the Provisioning Database that may trigger the generation ofreports providing information regarding domains, including TLDs andSLDs, that have been registered.

FIG. 12 depicts a report generating method 4200 according to oneembodiment. The method begins by determining that one or more reportsshould be generated (step 4210). Upon such a determination, a single setof generic reports may be generated that includes several TLDs (step4220). In such an embodiment, the single set of reports would bedata-driven based on what is populated in the Provisioning Database.

FIG. 13 depicts a report generating method 4300 according to anotherembodiment. The method begins by determining that one or more reportsshould be generated (step 4310). Upon such a determination, a set ofreports may be generated for each TLD (step 4320). The set of reportsmay be made available on an FTP server, whereby a TLD sub-directory maybe created in the FTP server based on the TLD name under a pre-definedparent directory.

FIG. 14 depicts a report generating method 4400 according to oneembodiment. The method begins by determining that one or more reportsshould be generated for Data Escrow (step 4410). Upon such adetermination, Escrow reports may be generated based on metadata storedin the Provisioning Database (step 4420). In addition, a target escrowagent may also be optionally generated based on metadata stored in theProvisioning Database when more than one available escrow agent may bechosen. Once the Escrow reports are generated, the Escrow reports may bepropagated to the Escrow Agent (step 4430). The propagation may occurusing a template-based approach where the TLD specific escrow depositsare partitioned by a scheme having a TLD sub-directory or a TLDindicator in the file names so that the TLD specific escrow deposits mayreside in a common directory. The format of the Data Escrow may bedriven by the Domain Manager to allow multiple Data Escrow providers tobe selected at the time that the TLD is created.

It will also be appreciated that one or more monitors may be provided bythe Domain Manager. For example, one or more system health monitors maybe provided that are implemented by looking for specific entries inlogs, by driving off of data persisted to the database, or by queryinterfaces. The one or more system health monitors may identify errorconditions and raise alerts in the event of errors. In addition, one ormore real-time runtime metrics may be provided. The one or morereal-time runtime metrics may increase visibility of the metrics of therunning system. In addition, Service Level Agreement (SLA) monitors maybe provided. The SLA monitors may measure availability and performancemetrics of the systems to demonstrate how the systems perform to SLAs.The SLA monitors may be driven by Registry Information meta-dataprovided by the systems. In addition, the automated enablement ofRegistrar systems with the addition of a new TLD could also apply to theSLA monitoring, where the SLA monitors may query for the available TLDs,then query for the features and policies of the available TLDs to drivethe SLA scenarios to run, and then execute the scenarios and sendresults in a generic form to generate combined or separated SLA reports.

The above described embodiments can be implemented using software,hardware, or a combination of hardware and software. The software may bestored on a memory, such as memory 1030, memory 1100, or memory 1130.Such memories may be RAM, ROM, hard disk, CD-ROM, DVD, flash drive, orany other computer readable medium capable of storing software. Thesoftware stored on a memory may be executed by a processor, such asprocessor 1020, processor 1090, or processor 1120, in order to implementthe above described embodiments.

Other embodiments of the invention will be apparent to those skilled inthe art from consideration of the specification and practice of theinvention disclosed herein. It is intended that the specification andexamples be considered as exemplary only, with a true scope and spiritof the invention being indicated by the following claims.

What is claimed is:
 1. A computer-implemented method of creating a newdomain, comprising: receiving domain data regarding an unregistereddomain at a first system, the domain data comprising a domain name anddata defining at least one of: services to be supported by the domain,features to be supported by the domain, or policies to be enforced bythe domain; creating a data structure comprising the domain data; andtransmitting the created data structure to a second system.